Advanced

If you already have an application connected to your gps, on a serial port, OpenCPN will not be able to connect to the same port. Two applications cannot use a port simultaneously . __On Linux use Gpsd in such a situation. Of course this only works if your “other application” supports the Gpsd. As an alternative on Linux you can use Kplex (also for Mac) or Muplex which can create pseudo terminals (“virtual serial ports”) to share NMEA data between applications.

If a NMEA sentence is filtered on an input connection and “LegacyInputCOMPortFilterBehaviour=1” setting in opencpn.conf|ini, it will still enter the internal multiplexer. So, it will be available to output connections, unless it's filtered there as well. If “LegacyInputCOMPortFilterBehaviour=0” then the message will not be placed on the internal multiplexer. This will only work for serial connections. Echoing back a network connection, on the input port for output, will not work

• NMEA data can also come from the VDR plugin. They will be labeled as such in the Debug Window and have “0” priority.

No Flow Control on Serial Ports By nature NMEA doesn't do flow control. If a message gets lost, it gets lost… It will be repeated at some point, and buffering a delayed message that has lost it's meaning, when there is more current & accurate data available is not useful. f interfacing the NMEA-specified way, there is no path for hardware flow control. It's not compatible with NMEA in any way.

Allow more flexible Regex Filtering. NOT IMPLEMENTED YET

See this PR

Background:

Often, there is more than one source sending position information, for example $GPRMC and $IIRMC.
The latter provides rather poor accuracy and needs to be rejected, otherwise the boat will “jump around” on the map.
But other data from this source like $IIDBT is of course needed. With the currently implemented filtering it is quite cumbersome
to find out the “bad guys on the bus” and do the job.

With this extension, filtering will be possible by inserting in the Opencpn.ini or Opencpn.config section [Settings/NMEADataSource] simple
wildcard patterns like

 ;.II[GZ]..,.IIRM.;

at the location where the filter strings are stored.

The matching will only apply, if the pattern does not have 2,3 or 5 characters.
This can be accomplished by inserting dots as wildcard characters.

Later the GUI settings dialogue may be adapted to support this and prevent wrong input.

Different GNSS systems work fine with OCPN, but if you like to use the “satellite status” instrument, named “GPS Status”, you may need to filter the data input to avoid flicker and needless flooding of the communications bus.

Using GSA / GSV for example, analyzing the UBLOX-M8N receiver optionally sends these sentences every second. When there is a significant number of satellites in view, this information occupies a lot of time in communication channels. Here is a real example: GSV (sats in view):

• GPS: 14,
• GLONASS: 9,
• 2 GSA sentences (one for each system),
• 4 GSV sentences (more than 70 bytes each) for the GPS constellation,
• 3 more GSV sentences for the GLONASS constellation.
• Maximum accepted number of GSV sentences for each constellation is 9 (NMEA Documentation).

If we think that it can also receive from Galileo and Beydou systems, we can already easily deduce that important navigation data can be delayed or even disappear. In conclusion, it does not seem reasonable use this information outside the environment of the GPS receiver itself, especially if we are using a standard NMEA0183 speed (4800 baud).

Typical multiple systems available: (Try using your phone's inbound GNSS):

• GP = GPS
• GL = Glonas
• GA = Galileo
• GB = BDS

What the GNSS board does is to combine what it gets to GNxxx for position sentences, like: GNGGA, GNRMC etc.. On the other hand is the satellite info divided into different xxGSV, GAGSV, GLGSV etc. So, without a filter in the connection set up the “GP status” instrument is rather nervous.

A small VDR extract:

$GPGSV,2,2,07,25,07,137,,26,67,250,,27,10,264,,8*5 9
$GLGSV,2,1,08,74,56,205,,66,07,336,,73,14,170,,76, 00,000,,1*73
$GLGSV,2,2,08,84,83,254,,83,31,052,,67,22,025,,68, 14,077,,1*77
$GAGSV,3,1,09,15,40,213,23,27,54,285,24,36,27,056, 24,02,07,149,,7*78
$GAGSV,3,2,09,04,10,009,,09,04,059,,19,00,000,,21, 09,314,,7*72
$GAGSV,3,3,09,30,52,175,,7*4D
$GAGSV,3,1,09,02,07,149,,04,10,009,,09,04,059,,15, 40,213,,1*7A
$GAGSV,3,2,09,19,00,000,,21,09,314,,27,54,285,,30, 52,175,,1*75
$GAGSV,3,3,09,36,27,056,,1*4F
$GQGSV,1,1,01,01,07,042,23,8*5C
$GBGSV,4,1,13,32,13,019,24,29,35,074,26,26,42,215, 30,20,18,071,23,1*7D
$GBGSV,4,2,13,08,18,036,25,02,01,104,,05,13,126,,1 2,07,246,,1*71
$GBGSV,4,3,13,13,41,053,,19,04,118,,24,43,286,,25, 05,330,,1*79
$GBGSV,4,4,13,35,82,164,,1*4B
$GBGSV,2,1,08,25,05,330,23,19,04,118,,20,18,071,,2 4,43,286,,5*7E
$GBGSV,2,2,08,26,42,215,,29,35,074,,32,13,019,,35, 82,164,,5*74
$GNGSA,A,3,05,18,29,,,,,,,,,,1.6,1.2,1.0,1*33
$GNGSA,A,3,27,,,,,,,,,,,,1.6,1.2,1.0,3*33
$GNGSA,A,3,08,20,26,29,32,,,,,,,,1.6,1.2,1.0,4*35
$GNVTG,,T,,M,0.0,N,0.0,K,A*3D
$GNDTM,P90,,0000.000024,S,00000.000000,E,0.967,W84 *50
$GNRMC,200336.00,A,5813.571276,N,01145.754249,E,0. 0,,200121,0.4,E,A,V*78
$GNGNS,200336.00,5813.571276,N,01145.754249,E,ANAA NN,09,1.2,33.0,39.0,,,V*1E
$GNGGA,200336.00,5813.571276,N,01145.754249,E,1,09 ,1.2,33.0,M,39.0,M,,*41

Use your Options > Connections > Inbound Input Filter with option “Accept Only Sentences” to limit the GNSS services by adding inbound services to the filter. See these two examples.

UDP data may be delivered to more than one system when sent to certain special addresses

A “broadcast address” is listened to by all devices on a network. It is normally formed by taking the network address (the first part of the IP address common to all systems on your local network) and setting the last part (the number which is different for every computer) to a value represented by all “1”s in binary. If all your devices' addresses start with “192.168.1”, your network's broadcast address will likely be 192.168.1.255 (255 is “11111111” in binary. This is why IPv4 addresses written like this never contain numbers higher than 255. Except for in the movie “The Net” and we don't talk about that). If you specify an address ending with “255”, OpenCPN assumes you mean a broadcast address. This is not always true but will result in desired behaviour in almost all cases.

The special broadcast address “255.255.255.255” is also listened to by all devices. It should not normally be used to transmit data from OpenCPN. Use your local network's broadcast address instead.

A “multicast address” is listened to only by devices which wish to receive information on that address. IPv4 addresses in the range 224.0.0.0 - 239.255.255.255 are multicast addresses. If you specify a multicast address for a UDP data connection, OpenCPN will tell your computer to listen for datagrams on that address. * More than one system may send data to broadcast or multicast addresses, so this is a “many to many” communications medium. * You cannot use broadcast or multicast addresses with TCP. TCP is a “one to one” connection.

Devices must to some extent process all broadcast packets on the network whether they are interested in them or not. Multicast packets are normally only seen by devices which have registered an interest in a particular multicast address. Consequently multicast is more efficient than broadcast although this is usually of little consequence in a small network. Despite being used by NMEA-over-IP protocols such as IEC 61162-4 and the forthcoming NMEA OneNet, NMEA-0183 over IP multicast is far less widely supported in marine applications than NMEA-0183 over IP broadcast.

There is no multicast address mandated for NMEA-0183 data in this context although you should avoid those addresses used by other protocols.

When using multicast with OpenCPN it is suggested that an address be used in the range 239.192.0.0/14 specified by RFC 2365 as the “Organization Local Scope”. If in doubt, try 239.194.4.4.

There is no mechanism in OpenCPN to specify the network interface through which multicast packets are sent or received. This will be determined by your system. In some cases it may be necessary to manually adjust your system's routing table to ensure that the desired network interface is used. Refer to your system's documentation if this proves necessary.

If you transmit UDP broadcast or multicast, then you should set the priority of the “real” NMEA input to something higher than the UDP stream. If not, prepare for problems. The reason is that if you are broadcasting, then you yourself will get the UDP message as well, which again will be retransmitted…… Obviously, it duplicates the “real” incoming data. Thus we get source priority flip-flop on each message, since they have the same priority. For example set the UDP priority to “0” and real incoming connection to “1” or higher. Multicast loopback is not disabled for consistency with broadcast behaviour. This means that priorities must be set as detailed above when transmitting over multicast, but multicast communication between multiple instances of OpenCPN on the same system remains possible. * The firewalls on some systems (e.g. OpenSuSE linux) may block broadcast and multicast data that you wish to receive. Refer to your system's documentation to determine how to allow such data to reach OpenCPN.

Also read about the Activating Routes and Active Route Console in Marks and Routes towards the bottom. It is essential to have turned on an Active Route in order to send waypoints to the Autopilot.

Also read about Route to Autopilot in Create Route and Route to Autopilot in Advanced Features for more details.

Refer to http://willkamp.com/opencpn/flyspray/index.php?do=details&task_id=1706 Check the cables and connectors and for USB Port timeout. How to Add or Remove “USB 3 Link Power Mangement” in Power Options in Windows 8 http://www.eightforums.com/tutorials/50276-power-options-add-remove-usb-3-link-power-mangement.html http://helpdeskgeek.com/windows-xp-tips/prevent-windows-from-powering-off-usb-device/

UDP is a method of transmitting data as simple “datagrams” without negotiating a connection between two endpoints. It involves no detection and retransmission of data lost in the network. Within a small home/boat network such data loss should not normally occur and in any case, NMEA data is generally updated by “talkers” on a regular basis. Unlike TCP which involves a connection between two endpoints, UDP data may be received by many “listeners”.

UDP “For UDP mode the IP address 127.0.0.1 is also known as localhost and used when sending to a client on the same machine. The IP address of any other machine on the network may be given.”

To reach all machines within a local network, like a wifi router, use the address 192.168.x.255 with the Protocol set at UDP.

  Example for a local net where the router address is 192.168.1.0:
  python VDRplayer.py Hakefjord.txt 192.168.1.255 10110 0.05 UDP
  Any receiving machine can then use IP address 0.0.0.0 and port 10110 in the connection properties

TCP For TCP mode the IP address is the address of the machine running VDRplayer. It may be localhost or 127.0.0.1 if the client is running on the same machine.

If VDRplayer is running on its own machine then give the IP address: of that machine that other clients can reach (e.g. 192.168.1.6 assuming that is the address of the machine running VDRplayer.py).

The Port Number: 10110 is somewhat arbitrary but it is the “undocumented standard” for NMEA over IP and must match the client receiver port number. Any port number permitted by the local firewall will work. It is best not to use well known port numbers such as 80, 22, etc.

The time delay of 0.05 (50mS) is the delay between each line in the file.

UDP received When adding a network connection for UDP receive there is no need to specify the IP address. The port is required but not the IP address. The sending end needs to specify both IP address and port number.